Contingent and external‑worker lifecycles were audited across the external namespace and source systems (PMS, partner portals, Meldeportale and HR feeds) and source contact records were corrected when erroneous elements produced external identities (for example pension‑insurance signature elements). Technicians repaired or recreated contingent‑worker records using managed forms so Okta and downstream systems could provision correctly, corrected employment type/employer associations with HR, and rebuilt or reconfigured misclassified accounts so work email addresses, licence entitlements and group memberships matched the employment type. Unique external usernames (for example .ext suffixes or numeric variants) were used to avoid collisions where true externals were required; in some cases internal sign‑in names were moved into the external namespace while retaining existing credentials so users kept immediate sign‑in while credential delivery and password resets were routed to private contacts. When automations reported failures such as 'user not found' or missing licences, technicians reactivated Okta/contingent‑worker records, repaired identifier mappings (deleting, merging or renaming duplicate or misspelled external identifiers), and retriggered or monitored downstream synchronisations to Atlassian, Microsoft 365/Exchange, AD/EntraID and other systems. Where asynchronous synchronisation was the root cause (for example AD <> EntraID sync failures or delays after mass deletions) technicians confirmed which accounts had been created in each system, re‑ran or waited for directory synchronisation, created missing EntraID objects when required, and then reapplied group and licence assignments; password‑reset flows scheduled for start dates were executed or reissued as part of remediation. Accounts that deactivated immediately due to erroneous start/end dates had end dates corrected, expiry flags cleared for indefinite engagements and accounts reactivated; anomalous source data (for example termination dates earlier than start dates) was recorded and later corrected via extension or reactivation workflows with written approvals captured in ticket metadata. Mailbox delivery and retention requests (for example researchers retaining institutional contact addresses for publications) were handled by externalization or by creating externalized mail profiles, aliases or forwarding so mail and historical data remained accessible while the primary address moved to an external namespace; where external employer associations interfered with personal subscriptions technicians unlinked external IU email records or used Okta flows to restore access. For large‑scale expiry or reactivation events technicians compiled validated account lists (cross‑checked against active contracts), executed controlled bulk Okta end‑date updates or bulk reactivations, and verified downstream licence reapplication; temporary application admin accounts with data‑protection reviewer oversight were used when central provisioning was blocked. When reactivation covered onboarding gaps required hardware and credentials were ordered and MFA provisioning was reissued to recorded private contacts. Authentication or MFA problems after reactivation were resolved by revoking stale sessions and tokens, reconciling and removing duplicate external accounts to leave a single active identity, and reissuing authenticator/MFA provisioning to the correct account. Atlassian‑created and automation‑driven accounts were reconciled with Okta identities to remove duplicates and ensure the correct account state and downstream synchronisations or application APIs were retriggered where required. Operational notes recorded written approvals and ticket metadata for manual interventions, though some tickets contained only final status entries.

Routine external-user reactivations and termination-date extensions normally completed when Automation-for-Jira processed approvals, the Atlassian API recorded the change (API notes sometimes appeared in German), and Okta automation set terminationDateExternal and assigned products/licenses. Where intermittent failures occurred, incidents were resolved using a consistent set of actions applied as needed. Transient RECOVERY/API states were cleared and Automation-for-Jira rules were re-run or targeted Atlassian API calls were issued when the platform returned inconsistent results; API logs sometimes contained German confirmation text (for example, “wurde gemacht”). Okta account classification errors and misclassified/deactivated records were corrected and manually reactivated when required. Username/email mismatches (including ".ext" variants and alternate personal emails) were reconciled so downstream reconcilers could find accounts. Password-reset or credential issues were addressed by reissuing password-reset notifications or resetting credentials when they were rejected. Entitlement gaps after reactivation were resolved by explicitly assigning Jira products/licenses or adding users to the appropriate Okta groups (examples included EPOS and other non-default apps) and by re-provisioning downstream services such as email, 1Password, and invoicing/billing tools. Profile updates recorded in the Atlassian API (manager, cost center, terminationDateExternal) were applied when present and confirmed in API logs. Stalled or misrouted approvals were fixed by updating authoritative approver records in upstream HR/source-of-truth systems, adjusting Jira workflow approver fields and CC-approvers, or by manually re-opening tickets and adding missing approvers; some workflows were validated to require only one of multiple approvers. Duplicate requests and locked form submissions were handled by cancelling duplicates, temporarily reactivating duplicates to allow processing, or accepting locked submissions and processing profile corrections via subsequent data-change tickets. When the Atlassian API reported an account as already ACTIVE, no reactivation was attempted and tickets were closed after contract/owner checks; when the API returned “Could not find any account with this address ” support marked the ticket as “Won’t Do” and required a valid existing account or a new account before reactivation. Separately, an Okta user-disable workflow was found to omit users because the user-search did not implement pagination and returned only the first 200 users; affected external users were manually disabled, the workflow was updated to add pagination so all users beyond the initial 200 were returned and handled, and the change was verified to return the full user set.

Incidents were resolved by restoring authoritative identity and application state and reconciling upstream records that produced lifecycle or classification changes. Administrators reactivated, unsuspended or extended accounts while preserving immutable IDs where feasible; when reactivation was denied for policy or privacy reasons, replacement vendor/guest accounts were provisioned and permissions were reassigned. Teams corrected HR/course/provisioning feeds and mappings (for example Workday IDs and course/section mappings), normalized extension/classification attributes, repaired dynamic‑group rules, removed stale external/domain accounts that caused misclassification, and reconciled or reconnected provisioning connectors and Deleted Users entries that blocked reprovisioning. Microsoft 365/Teams entitlement and workspace expiry failures were resolved by reapplying or extending licenses, disabling or renewing scheduled group/team expirations, confirming or reassigning active group owners so auto‑renewal flows completed, and re‑adding removed members/owners when source records required it; one lifecycle was manually extended in the Microsoft 365 admin center after the tenant UI button produced no action. Token and session errors cleared after account state restoration by reissuing tokens or prompting reauthentication; service principals and app registrations were rotated or reactivated when secrets had expired. Device and client issues were addressed by reconciling enrollment/licensing and local authentication state, clearing cached credentials or forcing sign‑out/sign‑in to apply new entitlements, and replacing hardware when necessary — one recurring JAMF Connect chain cleared after a password‑never‑expires flag was set which restored downstream Okta and GitLab access. Mail delivery and mailbox availability issues were investigated from Mail Delivery Subsystem transcripts and SMTP responses; suspended mailboxes were reactivated when appropriate. Confirmed cases showed deactivated accounts did not receive password‑reset or activation emails, so reactivation preceded successful self‑service resets. External/vendor or contingent accounts that only had a personal contact address sometimes required manager‑requested extensions; where alternate‑email recovery was missing, administrative extension or reactivation restored access. PowerApps (Power App) and form‑based workflows were impacted when the institutional account was terminated, producing stuck app screens or “wait for access” messages until the IU account state was restored or an alternate account was provided for invoice submission. Operational notes recorded provider timelines and helpdesk automation behaviours (including observed auto‑closure of no‑reply tickets) and typical propagation delays (minutes to ~30 minutes for most flows, with some classification/tagging changes taking up to 24–48 hours). As an operational safeguard, teams verified authoritative HR termination fields (for example Workday “Last day of Work”) before suspending access, accepted explicit stakeholder instructions not to suspend before an agreed exit date, and set helpdesk tickets to pending with a follow‑up date on the agreed exit date so suspension actions occurred at the correct time. Outcomes included restored application access and mailboxes, normalized dynamic‑group classification for SOC alerting, straightforward SaaS reactivations after HR or course‑owner confirmations, and replacement account provisioning when required; some requests were permanently denied after data‑protection or privacy review.

Access was restored by correcting account state and completing provisioning, and by resolving password, email delivery and MFA state issues. Administrators reactivated, unarchived, unlocked or recreated disabled/archived/locked/deleted accounts and re‑assigned Okta app assignments, permission groups and required licenses; some reactivations required manager or delegated approver authorization or submission to the owning service for non‑production environments. In several cases an incorrect or outdated email address on the account prevented a valid password‑reset flow; after correcting the account email a subsequent password reset completed successfully. Where self‑service was blocked, support performed admin‑initiated Okta account/password resets and reissued fresh password‑reset or verification links after correcting username/alias/sandbox typos, fixing wrong email addresses, and clearing or redirecting emails flagged as phishing. It was observed that password‑reset emails sometimes did not deliver while accounts were deactivated, so reactivation preceded successful reset delivery in those cases. Password‑reset and verification loops were resolved by issuing new valid tokens or by support performing the reset on behalf of the user. MFA issues were cleared by removing stale authenticator enrollments to allow re‑enrollment, launching apps from the Okta portal tile to clear app‑specific MFA state or to complete SSO when users lacked app usernames, generating temporary MFA bypass codes when devices or recovery codes were unavailable, or applying documented MFA exemptions for machine/bot accounts after owner approval. Browser, session and client specific failures were cleared by removing cookies/cache or exiting private/incognito sessions. Power BI paginated‑report access required signing into both Power BI web and Report Builder desktop with the same account. Vonage Contact Center access was restored by reactivating inactive/archived accounts and correcting per‑user Contact Pad/options, callback/outbound settings, supervisor/permission groups and inbound numbers (a disabled Vonage account produced the Chrome add‑in “Screen Lock” symptom). Miro access was restored by enabling the Miro app/license in Okta or converting a “Free”/“Free Restricted” account to a paid/full account and allowing short propagation time. In Care environments that lacked Okta connectivity and password sync, access was restored by using the care‑admin password‑based account after confirming the app lacked SSO. Administratively applied changes typically propagated within about 5–10 minutes; inactivity deactivation windows varied roughly 14–60 days (commonly ~30 days) and some services required a sign‑in within ~24 hours after reactivation to avoid immediate re‑deactivation. When dashboard or report access remained broken after reactivation, administrators validated and re‑assigned report/dashboard permissions and licenses or engaged report owners/owning services to restore access.

Workday changes were treated as the authoritative source and edits were classified (simple edit, reactivation to original HR ID, reprovision under a new HR ID, or Workday‑ID backswitch) before any renaming or reprovisioning. Operators recorded Okta rename invocations and originating Okta Workflows links and only executed renaming/reactivation/reprovisioning after identifying persona conflicts and downstream risks; automated renames preserved user formatting and preferred/display‑name preferences and were held or cancelled when unresolved conflicts or downstream risks existed. Renames were commonly scheduled in a 30–60 minute user‑offline window. Automation notifications and ready‑to‑run workflow links were observed to appear without explicit user confirmation; such automation‑only tickets were monitored and allowed to auto‑close after a 14‑day waiting period when no user confirmation arrived. When an expected rename trigger did not appear within ~1–2 days staff contacted Workday support. For Workday‑ID backswitches and reactivations directory objects were remapped to original employee IDs and Okta key‑user tools or UID resets were used to relink assignments and reapply entitlements. Staged or numeric‑suffixed Azure AD/UPN duplicates were consolidated or removed via tenant‑side merges, admin re‑invites, or account consolidations when downstream tenants retained separate identities. proxyAddresses and primary SMTP values were adjusted so legacy primary addresses were preserved as aliases (hidden from the GAL where appropriate); mailbox and license ownerships were reassigned and verified across HR/Okta/Azure logs to prevent mail routing or mailbox‑ownership anomalies. Observed directory/Office propagation windows were documented (primary SMTP/aliases: minutes to ~1 hour; Office profile/master data: ~48 hours; full directory metadata: ~2–14 days, with some sync paths completing in ~2–3 hours). MFA and authenticator enrollment failures tied to stale registrations were resolved by removing stale registrations or performing admin resets and re‑enrolling authenticators. Outlook and Teams profile inconsistencies were treated as directory/profile propagation issues and cleared by sign‑outs, client cache clears, profile rebuilds or local profile recreation and user reauthentication. OneDrive/SharePoint and notebook‑owner anomalies generally cleared after directory and Office metadata propagation. Devices with mismatched local usernames sometimes required local account rebuilds, device replacement, or Workday reverts; BitLocker or FileVault recovery keys were used when necessary. Downstream non‑SSO and third‑party tenants were remediated by tenant‑side merges, admin re‑invites, reauthentication or unlink/relink flows; vendor‑controlled tenancy issues were escalated to procurement or vendor support, and where internal support lacked access (for example a vendor PMS) users were directed to the vendor's service portal and the escalation was recorded. Legacy aliases or mail forwarding were preserved when immediate vendor changes were not possible to keep users reachable. Migration planning used automated availability checks to verify target UPN/SMTP availability and avoid duplicate aliases or routing collisions. Inventories identified which services used email/UPN as the user identifier versus a stable academyID/UUID to decide vendor mappings case‑by‑case. All rename invocations, remediation actions and vendor/procurement escalations were logged in a renaming checklist and communicated to affected users, including the final username/display/title and expected propagation timings. It was also observed that Okta renaming automations occasionally triggered on test/provisioning accounts and produced multiple automated tickets and external API errors when test addresses could not be used as ticket authors; those events were recorded as automation‑origin noise and handled according to the automation‑ticket monitoring and auto‑close policy. Separate incidents of post‑rename loss of access to VPN or mapped network drives were reported and treated as downstream SSO/credential anomalies; support noted that credentials remained unchanged in at least one case and the ticket was closed without further technical remediation when the user elected not to pursue additional action.

Inconsistent offboarding and device state issues were resolved by coordinating identity controls, fixing automation race conditions, introducing device‑quarantine actions, reconciling accounts, re‑enrolling devices, auditing downstream entitlements, and tightening hardware‑return logistics and communications. Key outcomes included:

Recurrence was reduced by documenting partial‑offboarding cases in Jira, fixing cleanup scripts and unreliable imports, adding logging/monitoring around suspend/unsuspend flows, and tightening return‑label generation, delivery confirmation and inventory verification to avoid mismatches, unrecovered assets and reimbursement disputes.

Investigators found the MEMBWE bulk selection and downstream workflows relied on MT.Entered_Date and related logic that misclassified reinstatements as automatic renewals and triggered honours, access activation, and MEMBWE communications before payments were allocated. Remediation combined two changes. First, the bulk-selection and workflow logic was changed to reference MT/MTI indicators that distinguish reinstatements from renewals so reinstatements were excluded from automatic-renewal classification. Second, all send/assignment/activation paths (welcome-letter/honours assignment and access activation/expiry calculation) were gated by membership/payment state: invoices continued to be created on reinstatement, but honours, welcome-mail scheduling and access activation/expiry were deferred until payment allocation/validation was confirmed. The access/expiry calculation was corrected to use payment/validation (allocation) date as the activation baseline so stored expiry dates matched confirmation emails from the registration/CRT systems. The changes touched Membership System batch jobs, MEMBWE/LetterWriter send logic, invoicing/payment allocation checks, and registration/CRT expiry sources; membership DB usage was standardised to MT/MTI indicators and allocation/date fields to prevent recurrence.

Investigations identified duplicate, legacy or preexisting external identities and restored access by consolidating authoritative credentials, identifiers and attributes onto a single active canonical iu.org account whenever possible. Primary enterprise addresses, Academy‑IDs/EPOS AcIDs, course bookings, permissions and permission mappings were moved to the active profile and erroneous records were archived, set inactive, or removed so mailbox ownership and password‑reset flows routed to the canonical identity. Directory and mail remediation work included consolidating primary login names and enterprise addresses, adjusting aliases, clearing stale sessions and cached credentials, re‑triggering directory synchronisations, and removing duplicate LDAP/AD entries (including legacy on‑prem accounts that co‑existed with cloud identities). Stale or inactive Exchange/Office365 mailboxes that produced NDRs or repeated Outlook password prompts were hidden, deactivated or consolidated; mailbox contents were copied from legacy mailboxes into the active mailbox when preservation was required. Duplicate Okta entries were removed or matched to the canonical Okta user (actions performed in the Okta Admin Console when appropriate) so the active Okta ID owned the enterprise address and attributes; old/deactivated records were left inactive when appropriate. Orphaned MFA bindings were removed and users were allowed to re‑enrol. Partial service states (for example myCampus and Teams operating on different accounts) were resolved by reassigning active account ownership for each service or removing legacy/external bindings so services authenticated consistently against the canonical identity; Microsoft Teams chat histories remained associated with the original identity and could not be merged. EPOS/myCampus disparities were resolved by verifying authoritative EPOS mappings, transferring enrollments and links to the correct account, and setting duplicate EPOS entries inactive rather than deleting them when appropriate. Where CARE merges were blocked because of EPOS and IAM dependencies, teams documented which bookings and accounts belonged together as a pragmatic workaround. Salesforce and vendor merge errors were corrected and missing IAM profiles were recreated (for example by replaying academic-profile.ProfileUpdated events via Conduktor) so downstream systems recovered records. Where directory writes or vendor merges were blocked, accounts were dissociated or legacy third‑party accounts deleted after owner verification and licences, group memberships and permission mappings were reassigned so project data became accessible. Support manually set or reset passwords in authoritative stores when self‑service password resets failed (including HTTP 400 errors) and validated that authentication flows subsequently routed to the canonical identity. Incorrect email mappings that blocked application licence assignment were corrected so the active identity matched the enterprise address and licensing could be applied. Duplicate provisioning requests were handled by confirming existing accounts and performing password resets rather than creating new profiles when appropriate. Investigations identified IAM/UI search limitations that hid archived profiles; duplicates hidden by that behaviour were located, merged or removed and email addresses (for example non‑enterprise addresses mistakenly assigned to duplicates) were reassigned to the correct active account, and the IAM/usability issue was raised with the owning team. Operational teams confirmed queue and capacity limits and escalated or redirected consolidation requests to the authoritative team, vendor or service portal when necessary; where full consolidation was prevented by third‑party product limitations, ownership was reassigned and mitigations preserved. For externally linked social profiles (for example LinkedIn) that could not be removed via the internal UI, users were directed to the People‑Projects team to request removal and advised to escalate to LinkedIn Support if People‑Projects could not resolve the linkage. Additionally, investigations discovered application‑level approval states (for example MyLIBF/DCWeb surfacing 'User account approval needed') that could remain set after accounts were merged and block portal logins or certificate downloads; these incidents were resolved by updating the application approval state and re‑provisioning the merged identity or by coordinating approval with the portal owners so the canonical account became usable.

Account provisioning, activation and verification failures were resolved by restoring alignment between authoritative identity records and downstream tenant/service records, repairing or reprovisioning downstream identities, and coordinating with application or vendor owners when vendor-side state prevented recovery. Key actions taken included:

These combined actions restored expected account activation and verification email delivery, mailbox and alias creation, display name accuracy, application and license entitlements, and where applicable recovered or escalated vendor-held data after migrations.

Ownership, access, and suspension failures across third‑party SaaS, vendor, and internal service accounts were resolved by reassigning ownership and sign‑ins to canonical IT‑managed service accounts or verified shared mailboxes after mailbox access was confirmed. Microsoft Forms ownership cases (including forms embedded in SharePoint) were resolved by applying Microsoft’s Forms ownership‑transfer guidance to reassign ownership when the recorded owner was a departed or inactive user. Where secrets or credentials had been lost because values were retrieved from a secret manager without being recorded, credentials were rotated and temporary one‑time secrets were issued via the organisation’s secret manager with passwords set to change at first login; secret delivery channels were controlled and users were informed about secure storage. Archived or deactivated vendor accounts were located (including under alternate or maiden names) and reactivated where possible; when invitations or resets had expired or accounts were unrecoverable, affected accounts were recreated, permissions were replicated from reference users, and functionality was tested before closure. Gated API/bot claims and first‑time invitations were accepted using dedicated service mailboxes or reissued invitations; provider sign‑in reset flows and vendor support were used to regain control when available. SSO, phone‑number verification, and licence‑portal bindings that prevented transfers were addressed through coordination with licence administrators, procurement, or vendor support to detach personal verification methods, reassign billing contacts or cost centres, or authorise institutional sign‑ups. Deleted or inactive Azure AD/Entra and Microsoft 365 user states were reviewed and cleaned; licences were freed in licence‑management portals and effective dates were recorded before subscription changes. Vendor billing holds and account suspensions tied to invoices were handled with accounts‑receivable and procurement to clear or dispute invoices or to arrange temporary backup accounts to maintain critical vendor functionality. Unused IT service accounts and associated platform artifacts were retired and unsupported account requests were closed with clarified ownership and links to the organisation’s business‑account process and secure credential storage guidance. Login failures caused by platforms that required a username rather than an email address were resolved by using the platform’s expected identifier during recovery flows. Platform organisation/billing context issues were resolved by switching the account/organisation selector to the intended institutional account. For SaaS cleanup cases, accounts were updated to unify inconsistent email domains and inactive employee accounts (last login > 6 months) were removed; individual account migrations or relocations were performed where required to preserve active user access and continuity.

A dedicated service/admin account was provisioned and assigned only the admin/roles needed for incident-response actions (for Okta this included password reset and session management; for Auth0 it included the appropriate API scopes). API tokens were created under that service account so tokens inherited only the scoped permissions of a team-owned account rather than an individual. The active token and account credentials were stored in the Incident Response vault in 1Password to centralize ownership and lifecycle management; the service account required a password reset email to activate access after creation. It was observed that authenticated tokens with insufficient authorization or wrong audience returned 403 Forbidden from downstream APIs (examples: GET /student-enrolment/v1/profiles returned 403). Misconfigured audiences had been a cause; the correct audience values for the affected systems were https://iam.iu.org for EPOS and https://api.iu.org for the API. The approach was applied consistently across production, staging, and development environments.

Support first located the user’s corporate account and any recovery contacts and confirmed usernames when they were unknown or duplicated. When passwords were at issue, Okta and application passwords were reset and reset notifications were delivered to recovery/private email addresses; after users set new passwords they regained SSO and cloud service access where endpoints accepted the updated credentials. For 1Password Secret Key loss, users either completed the vendor recovery flow from the 1Password recovery email (self‑service) or administrators performed an administrator‑initiated account recovery and completed required admin confirmations; support verified the recovery and restored access. Campus account lock conditions were unlocked in EPOS/MyCampus or referred to Study Support for administratively locked student accounts. Temporary local device locks or rate‑limits were observed to expire and allowed subsequent sign‑in retries. When authentication was blocked by device‑bound factors or misbound methods, administrators removed or reset Okta authentication‑method bindings and reconfigured Okta Verify and Windows Hello so users could re‑enroll; activation codes for Windows sign‑in were provided when required. Okta factor language/locale mismatches were resolved by adjusting factor/account locale or verification bindings; persistent keyboard/locale mismatches sometimes required re‑enrollment or OS reinstallation. Devices absent from Intune were added to inventory or re‑enrolled so enrollment and device policies could complete. In multiple cases where newly reset passwords were accepted elsewhere but rejected by the corporate device and profile setup repeatedly failed, a full OS reinstall/reimage or re‑enrollment restored sign‑in, profile setup, and correct keyboard/locale behavior; some devices continued to use a cached old password until reinstallation or re‑enrollment. When Windows presented unfamiliar login or drive‑encryption recovery screens (including BitLocker prompts), support retrieved the device recovery key from escrow or an authorized colleague and guided the user through entry of the recovery key; access was restored without reimage where the recovery key cleared the encryption lock. Windows initial setup failures reporting error 801c03ed were resolved after the user’s account/profile settings and Windows management/group membership were corrected. Temporary profile issues on shared servers (for example JUMP) were resolved by removing temporary profile registry entries so normal Start menu, desktop shortcuts, and saved profile settings returned. For users returning from extended leave, account status was verified before resets and on‑site hardware inspection was offered when long inactivity suggested hardware issues. On macOS (including Apple Silicon), some initial‑enrollment failures required wiping and reinstalling macOS via macOS Recovery and removal of FileVault‑protected volumes (for example using erase‑volume‑group) so the device could be re‑enrolled and accept SSO credentials. After macOS reinstall and enrollment, SSO and Microsoft Teams authentication/screen‑sharing resumed and previously inaccessible internal KB links became reachable once account acceptance was restored. In several incidents a macOS login showed an account‑lock countdown and both old and new passwords failed while the FileVault recovery prompt or Wi‑Fi/network icon was not present at the pre‑login screen; these cases were resolved during interactive remote support sessions where support used the provided FileVault recovery key and restored the device to an unlocked state, or otherwise completed remote remediation that restored network/recovery visibility. Following OS reinstall, application licensing (for example Adobe Creative Cloud) sometimes required license reassignment or re‑provisioning; support verified licenses were assigned and restored access to licensed applications. Support provided step‑by‑step reinstallation guidance where needed and verified device enrollment and account unlocks.

Access failures were resolved by restoring user records and account state to a known-good configuration and synchronizing entitlements across related systems. Work that resolved incidents included reactivating or unfreezing accounts (sometimes temporarily for contract work before re-deactivation); correcting Salesforce Profile, Campus, Team and position attributes to match a functioning reference account; restoring permission-set assignments (examples applied in incidents included Case Management - DS - OnCampus - Basic, ConsentManagement, DS Campus Office, Lightning Email Templates Access Permission - Basic, and Manage Activities); and reinstating public-group and queue memberships so case queues and case-management workflows became visible. Several incidents traced to contract reassignments or contract records not shared with required teams, which removed position memberships and thereby revoked permissions; re-establishing the correct contract/position sharing or reassigning positions restored access. Support mirrored a reference user’s entitlements across systems (examples included Office account entitlements, EPOS/CARE permissions and myCampus access) and verified that permissions matched the reference account. Missing MyCampus menu items were resolved by assigning the appropriate MyCampus role (for example assigning the Academic Lecturer role to accounts that appeared as student accounts), with propagation delays noted. When repair was impractical, a new Salesforce user was provisioned and the settings of a functioning account were cloned; accounts were preserved via deactivation or freezing rather than deletion for temporary absences or administrative transitions. For incidents involving identity provider provisioning, additional steps resolved mapping and login discrepancies: Okta–Salesforce group/provisioning mappings that created duplicate or incorrectly profiled Salesforce users were corrected by restoring the intended Okta group memberships or updating the provisioning mapping so the Okta account linked to the correct Salesforce user; Okta deprovisioning/reactivation was reverted where it had removed entitlements. Cases where direct Salesforce login failed while Okta SSO still worked were traced to hardware MFA (YubiKey) registration or PIN changes; these were addressed by re-registering or restoring the user’s MFA device registration or by resolving Okta mapping so SSO authenticated into the correctly profiled Salesforce account. Administrative attempts to rename or re-link Salesforce usernames were sometimes blocked by Salesforce–Okta sync constraints and were handled by making the corresponding change in the IdP/provisioning layer or by reinstating the original provisioning state. Support teams performed the corrections or provisioning and notified users directly (for example via Microsoft Teams) or provided the Jira Service Desk self-service portal link when reactivation or entitlement updates were completed.

Access options shown in the Self Service Minion were tied to the device's AdminGroup membership in AD. Two resolved scenarios were documented: short-term temporary admin: the user had no Minion entry and could not obtain the 30-minute admin session; the user was added to the appropriate AD short-term Mac admin group, the Minion entry then appeared in Self Service, and the user obtained the 30-minute admin rights needed for screen sharing. long-term persistent admin: the Mac's AdminGroup membership was changed from Shortterm to Longterm, the device was restarted, and the Service Portal Minion entry was used to request/grant the 3-year admin session in Self Service; the 3-year option then appeared and the user confirmed elevated access functioned as expected.

Support validated that the inquiry related to the Munich StudSek queue and confirmed the Munich queues had already been migrated to ServiceCloud. The queue's email address had been switched so new requests were routed to ServiceCloud (Salesforce) rather than OTRS, so there was no need to individually reactivate the user's OTRS account. The user was informed of the migration and the ticket was closed.

Support reconciled application identities with corporate identity records so primary account email and username values matched the corporate identity and duplicate or legacy application accounts were merged or removed. Where content, memberships, or licenses were split across identities, ownership or space permissions were reassigned or content was transferred to the primary account and Atlassian accounts were reactivated when required. Legacy external addresses on application identities were replaced with the corporate address (private addresses were retained as secondary contacts in some cases) so password‑reset emails and notifications were delivered to the corrected identity. Okta‑to‑application assignments and SSO/provisioning mappings were verified and corrected and surname/username values were fixed so sign‑in and password‑reset flows completed. OpsGenie memberships and Atlassian Service Management license associations were restored after merges/reactivations. In cases where device or Office provisioning remained associated with a legacy identity, locating the user’s Company/Enterprise Portal welcome email and reinstalling Office via that portal resolved missing Office apps on new hardware. Support also advised users to explicitly sign in with their specific primary email alias when multiple aliases existed (this resolved an email/Teams access failure in at least one case) and escalated to Digital Technologies/IT Helpdesk when necessary. Support observed that permission or reactivation changes sometimes took time to propagate, that explicit owner‑level permissions were required to access specific Jira boards or Confluence spaces, and that clearing browser cache/cookies helped persistent sign‑in issues.

Support confirmed whether mailbox or account contents required retention. When no retention was required, administrators removed, deleted, or deactivated the specified Microsoft 365 user accounts (including student accounts on organizational and personal domains, e.g., iu-study.org and freenet.de), decommissioned service and podcast mailboxes, and deactivated external .ext accounts. Related application accesses — including MyCampus, Care, Epos, and community access — were locked, suspended, or revoked as requested. When requesters did not provide an IU email address, staff searched connected application records (for example Care) for external email identifiers to locate the account; when no Microsoft 365 account was found, that result was recorded and communicated to the requester. All deletion and access-lock actions were recorded by administrators (for example Microsoft 365 deletions recorded by Sabrina Filz; Epos and community locks recorded by Magdalena Kügel). No deletion or deactivation errors were reported and requesters were informed when actions completed.

Support observed that Apple had begun classifying the institution’s domain as claimed and in some cases treated IT‑provisioned institutional addresses as private Apple IDs. Many accounts were restored when users completed Apple’s “Forgot password” flow or reactivated the account through a browser on the device; reactivation in several instances freed the institutional address so administrators could proceed with domain‑claim/Apple Business Manager tasks. Accepting or creating a free @icloud.com address (including Apple‑offered temporary addresses) stopped repeated sign‑in prompts and restored App Store update capability and app access; creating a new free @icloud.com address also permitted App Store updates while an original account remained disabled. Adding and verifying a private (non‑institutional) email on the Apple ID enabled migration in numerous cases, though some attempts to change sign‑in emails failed with “This email address is not available.” Accounts that lacked a valid password, recovery contacts, or had two‑factor authentication tied to decommissioned company phone numbers required Apple Support–assisted account recovery and identity verification; support was unable to change trusted phone numbers for private Apple IDs without account owner or Apple intervention. When users were blocked from creating a new Apple ID with their institutional email, alternatives included creating an Apple ID with a different email domain or creating a Business Apple ID (the latter limited independent purchasing/downloading in several cases). In at least one case changing the account’s sign‑in email to an appropriate business address caused Apple to treat the account as a Business account and resolved migration notifications. Support validated the legitimacy of Apple’s notices when users suspected phishing and inspected device/App Store/MDM state when relevant. Additional observed macOS behavior included the iCloud “Sign Out” hanging with a spinning icon and affected Macs not listing devices correctly; multiple restarts often did not resolve the hang, support offered remote sessions to investigate, and some situations required Apple intervention or remained unresolved in the ticket record.

Support restored Okta and downstream access by reconciling identity records and performing targeted administrative account actions. Technicians reactivated or re‑imported missing or disabled Okta accounts, corrected or consolidated alternate IU usernames and identity records, and reconciled internalization changes (external→internal) that blocked activation or reset flows. Administrators performed admin‑initiated Okta password resets to generate new activation/password‑setup tokens and regenerated or resent expired activation/reset notifications to external/private recovery addresses; they also updated locked or greyed‑out primary‑email fields so notifications delivered to the correct address. For contingent workers, reactivations and term/extension changes were completed via the Manage Contingent Worker Account form or by routing requests to the Dozierendenguides team; Okta license renewals/extensions or end dates were applied as needed. Support cleared application‑specific access blocks by prompting hostkey/notification resends, remediating app‑side tokens, refreshing application‑level credentials and regenerating tokens when a recently reset password worked on one device but not others, and confirmed users were signing in via the correct Okta URL (okta.iu.org) when URL confusion was a factor. Cases where a successful Okta sign‑in did not surface application tiles were escalated for application‑access investigation. Automation and provisioning APIs (Atlassian/automation) sometimes reported accounts as active or in a RECOVERY state even when activation links had expired; in those cases tickets were occasionally closed when automation indicated an active account and no further requester confirmation was provided. These combined actions restored downstream access to Microsoft 365/Office 365 (Outlook, Teams), myCampus, Care, Vonage, 1Password, Atlassian and PowerApps.

Support first determined whether authentication was controlled by Okta or by the application owner and then applied the appropriate remediation. For Okta‑managed accounts, support verified the primary Okta authentication state, checked for expired credentials, and unlocked or reactivated accounts that were locked or blocked by repeated failures or suspicious‑activity detection. Support retriggered or resent activation and password‑reset emails to users’ registered or alternate/external addresses (including personal Gmail/Hotmail/GMX) when delivery failed or links expired and confirmed the correct recipient before proceeding. Administrative unblocks or clearances of security block flags were performed when unblock links or password changes did not clear blocks; support investigated “Blocked Access Attempt” notifications (including referenced IPs) as part of that work. Admin‑initiated password resets were used when self‑service flows failed because a second factor or mailbox access was unavailable; in one instance a user set a new password via the workstation startup password change flow. Support corrected cases of users authenticating at the wrong endpoint and replaced expired or delayed links. For device‑specific failures, affected devices were re‑authenticated after credential changes to restore OneDrive sync and cloud access; desktop Office apps returned from read‑only to editable after re‑authentication in reported cases. For applications not controlled through Okta (for example Atlassian via a Shibboleth proxy, FONTO via the IU Portal, or Workday), support either referred users to the application owner or performed account resets when the request was within support scope; a Workday account reset was completed on request in one incident. Okta Verify enrollment prompts (QR) sometimes did not appear in the client UI; logs occasionally showed Okta Verify authentication occurring shortly after without further intervention, and tickets were closed once the user confirmed access was restored. Temporary credentials, reset instructions, or status updates were sometimes communicated via Microsoft Teams or email. After unlocking/reactivation, password resets, administrative unblocks, or referral/resets to the appropriate owner, Okta and downstream SSO access was restored in the reported incidents.

Incidents were resolved by reactivating the inactive Salesforce user record in the org’s backend/admin console. Reactivation typically restored direct and SSO sign‑ins after a short propagation period (generally a few minutes up to about 5–10 minutes). Where password‑reset links had failed or reset flows had looped while the record was inactive, reactivation followed by issuing a new password‑reset link allowed the user to set a new password and sign in; delivery of password‑reset links to alternate emails was handled case‑by‑case. Reactivation restored the ability to be @‑mentioned/linked in Salesforce records and cleared Salesforce Authenticator “cannot connect to the server” errors (one case required re‑linking the Authenticator app after a phone change). Reactivation did not automatically restore mirrored or downstream entitlements (for example Care or Academy5), which required separate access requests. Administrators sometimes updated team/contact fields on the user record during reactivation. Reactivation occasionally exposed unrelated in‑product integration errors (for example Vonage) that required separate incidents; in one case the user’s Salesforce signature image remained missing after reactivation and required profile support. Reported environments enforced automatic inactivity deactivation with varying windows — in some orgs this window was extremely short (an observed example of 24 hours), in others ~14–30+ days — and support sometimes declined reactivation when an immediate re‑deactivation was expected. Support reassured requesters that inactive status did not equate to account deletion. Tickets in the reported set were typically marked Done and auto‑closed by Automation for Jira after 14 days with no user reply.

Standard external‑worker termination‑date extensions and reactivations had been processed through the IT Service Portal (and occasionally Atlassian Assist) into Automation for Jira approval workflows and Okta automation. When approvals completed an Atlassian API service account recorded the updated termination/exit date and Okta automation applied that termination_date to the Okta account and downstream IU provisioning; the change was logged in Jira and technicians closed the ticket. Approval reminders were sent by Automation for Jira and requests were auto‑closed as “Won’t Do” after a configured 14‑day approval timeout; in timed‑out or explicitly declined cases the Okta termination/expiration date often remained unchanged, which led to unexpected deactivations. In some incidents deactivation requests were incorrectly handled as termination‑date extensions rather than account disablements, requiring corrective follow‑up. Nonstandard renewals, reactivations, and expired accounts were handled manually on a case‑by‑case basis and included manually updating Okta termination/expiration dates and licenses, reactivating Okta accounts, adjusting or reactivating downstream system accounts (for example AB Tasty and Office365/mailboxes), and sending Okta password‑reset messages to a user’s private email after reactivation. Short interim extensions were sometimes applied to prevent immediate deactivation while account or email attributes were clarified. At year‑end batches of external accounts were deactivated when managers did not respond to expiry reminders; several reactivated accounts entered a “Pending user action. User password selection required” state after reactivation. Automated systems typically did not emit technical error codes and operational logs sometimes contained localized German messages. The Automation for Jira approval reminder had previously used an outdated portal link and was updated so subsequent reminders pointed to the correct Jira ticket/ticket type.

Extension requests remained in a pending 'waiting approver' state until a valid approver acted, an approver field was corrected, the request was canceled, or Automation for Jira auto-declined the request after extended inactivity (~14 days). Where a CC-only approver had been set the workflow awaited the designated approver's approval; once that approval occurred the Atlassian API returned confirmation and the Okta automation applied the updated termination/end date. Where wrong approver or cost-center ownership was entered technicians either corrected approver metadata or closed/canceled the request; in those cases no change to the existing termination date was applied. When the designated approver did not recognize the external user Automation for Jira sent repeated email reminders and the request was automatically declined and closed after the system timeout. Technicians informed requesters about correct approver and cost-center ownership and noted when ticket-permission limitations prevented requesters from closing or reassigning requests, which required resubmission by the proper approver. IT teams indicated they did not have visibility into academic contracts and therefore could not initiate or approve extensions on behalf of academic departments; requesters were instructed to have the academic responsible person or department submit the extension request or to escalate to Dozierenden Guides. Incidents showing discrepancies between requested dates and authoritative reports were handled case-by-case (for example, closed as “Won't Do” and resubmitted to the correct approver), and account termination dates were verified after approval, cancellation, or resubmission.

An Okta attribute review was completed with the stakeholder to confirm available fields. A report was created containing the agreed fields: E-mail, Status, terminationdate, businessUnit, Cost_Center2, and employeeType. An initial report export was sent to the stakeholder for validation. Automation for Jira was then configured to deliver the report every Monday at 07:00. The scheduled delivery was confirmed and the ticket was closed.

Two resolution patterns were used depending on the root cause. For phantom Microsoft Forms submissions that prevented creating a new request and left provisioning queued in Automation for Jira, support sent a manual invitation email that allowed the user to create the account with their email; this bypassed the Automation for Jira approval queue and restored provisioning. For requests that were redundant because the account already existed (including external provider accounts such as OpenAI), support checked the user directory and the external provider account status (for example, OpenAI showed the account as 'normaluser'), confirmed prior login activity where present, and cancelled/closed the Jira ticket as unnecessary (resolution: Won't Do). When Microsoft Forms enforced a single-entry-per-user and an external provider's activation/invitation link had expired, support noted the form limitation, verified the external account state, and informed the requester; if the provider would not reissue an activation link, users were redirected to alternate support channels (e.g., Microsoft Teams) or the ticket was closed as not actionable from the internal provisioning workflow.

Support inspected affected users' Okta profiles and linked IU Office accounts and verified the Okta account state and Preference Survey app license assignment. In cases where Okta and the IU Office account were active and a license was present, support found no account freeze or license misassignment and concluded the disabled form fields were not caused by Okta/IU Office account status. For tickets where the Preference Survey showed the account status as 'Nicht aktiv', support identified the app as part of the Lehrenden‑Apps suite and noted that that app-managed account state was outside IT's remit; support did not change the account and directed requesters to the Lehrenden‑Apps team (s.ds-lehrplanungsapp@iu.org) and the Lehrenden semester‑planning SharePoint page for further handling. The combined observations indicated two common outcomes: (1) UI/ app-side interaction problems despite active Okta/IU Office accounts and licenses, and (2) app-managed 'Nicht aktiv' account states that required Lehrenden‑Apps team action.

The issue was caused by a deactivated or unprovisioned Salesforce account (often due to >30 days of inactivity) and was resolved by reactivating the user’s Salesforce account in the appropriate org (including Salesforce Production when applicable). Support verified the user signed into Okta and launched Salesforce via Okta SSO; verifying the Okta session and signing in through Okta restored interactive access. When users attempted to sign in with a previous password and did not receive password‑reset emails, support confirmed the account state and reactivated the account; teams noted and acted on a short post‑reactivation window (about 1–2 days) during which the user needed to sign in to avoid immediate re‑deactivation. In cases where entitlements or API access remained missing after reactivation, support identified a reference user (for example, Laura Hörterer or Steffen Slavetinsky) and copied that user’s Salesforce profile/permissions to the affected account so entitlements matched the required profile. Requests for Salesforce API access and client credentials (client key/secret) were processed in conjunction with the profile/permission change to ensure the account had the appropriate API/profile privileges.

The Okta renaming automation was triggered and the username/email was updated (old username/email changed to the new Workday-provided identity). VPN access instructions were sent to the user's private email address. Egencia and myCampus update requests were created/assigned to the appropriate contacts, and the Mac was backed up and fully erased/reinstalled to handle the FileVault/T2 requirements prior to re-provisioning.

Technicians first verified the account record and status in Okta to determine whether the identity account remained active or had reached its institutional end date. When the Okta identity was active but users could not sign in, support initiated identity‑level password/account resets and, when necessary, application‑level resets (for example Office/Outlook and myCampus). Reset messages were delivered to the email address on file—typically the user’s IU‑Mail account but sometimes an external address (for example gmx.de or aol.com)—and those resets restored access to Okta, IU‑Mail, Office/myCampus and downstream services in documented cases. Several incidents recorded no delivery of 2‑factor authentication prompts. Where the account had actually reached its end date or been deactivated after a missed extension window, support advised that a supervisor‑initiated extension (via the Dozierenden Guide) was required to reactivate the account; in some tickets agents closed after advising supervisors to request an extension when reactivation had not yet been completed.

Two distinct classes of root cause produced the same symptom (a user could not sign in via SSO or continued to consume a license while the target app account remained active), and both classes were observed and resolved in production cases. For connector-backed provisioning where the connector retained a matching record after the central account was deactivated, support re-imported the user via the provisioning/import process, reactivated the central account, and matched the reactivated account to the existing record on the provisioning connector; restoring that linkage returned the account to a usable state. For SAML/JIT provisioning (which does not emit deprovision events) teams moved affected apps to a provisioning method that supported deprovisioning (for example, enabling SCIM where available) or implemented an out‑of‑band deprovision mechanism; examples of out‑of‑band approaches included Okta Workflows or webhooks that deactivated or deleted the target application account when the central account or app assignment was removed. Separately, incidents were caused by source‑of‑truth lifecycle and administrative‑ownership issues (for example, exmatriculation recorded in Salesforce while the M365 account remained due to retention windows or delegated administration). Those cases were resolved by engaging the owning team (for example, student‑account support) or using the appropriate delegated admin tool (for example, manual M365 account deletion via a Powerapp) to remove the account in the target application. Reported user‑facing symptoms included generic authentication failures from the identity provider and no explicit deprovision error from the target application; resolution required either restoring the provisioning linkage or ensuring the source system and administrative owner completed account deletion or an out‑of‑band deprovision.

A temporary test account (alex.vasiliauskas-test.ext@iu.org) was created via the provisioning system using the Atlassian API. The account was configured so that on the scheduled start date a password-reset email would be sent to the user's private email address. The ticket was completed after the account was created and the password-reset delivery was scheduled despite the earlier automation warning.

Administrators reactivated Salesforce user records that had been disabled by inactivity/decay; re-enabling the user restored login access. In some cases credentials were expired or unknown and support also reset passwords and sent password-reset emails, but password-reset attempts performed while the user record remained inactive often did not succeed. After reactivation, users were advised to log in promptly (typically within 24 hours) to avoid automated re-deactivation; affected users subsequently confirmed successful login.

Support confirmed they did not have access to third-party PMS account-management tools (for example, SiteFusion). For new account requests, account-unlock errors ("account is locked"), and permission changes in vendor-managed PMS, support routed requesters to the vendor's dedicated Service Portal or vendor-specific account-request form and closed tickets after rerouting. Support noted that password-reset/"forgot password" workflows were sometimes disabled while the account remained locked and that saved browser credentials did not bypass a locked account. Where requesters completed the vendor portal/form request, the vendor provisioned or unlocked the PMS account and referenced the user specified in the vendor request. Support informed users to contact the responsible application/PMS owners when vendor intervention was required.

Immediate access for an affected user was restored by extending the account termination/end date via Okta automation so the Office account remained active. Investigation showed instructor accounts had been reassigned to Microsoft 365 SKUs that were web-only (office.com), which removed entitlement to desktop Office applications. Where users could not open or complete documents (for example, evaluation forms in the My IU Teacher Portal) and reported messages like 'license was locked/disabled,' they were informed that the assigned SKU did not include desktop app access and were directed to sign in through the Okta dashboard and use the Office web applications to access and edit those documents. The web-only SKU assignments persisted beyond termination-date changes and required separate corrective license reassignment to restore desktop Office access.

Support manually reactivated the affected Microsoft/Azure AD and Jira accounts, after which the user confirmed service access and presence were restored. Investigation noted that no manual administrative lock had been applied; a recent HR record change (job-title update and hire date set to 1.7.2024) likely triggered the automated suspension rules that disabled the accounts.

The incident was resolved by reactivating the user's Production Salesforce account to restore immediate access and provisioning a separate Staging/UAT account to satisfy the request for an isolated test environment. The request for profile-switching between Production and UAT was recorded alongside the account provisioning actions. The unrelated GitLab issue was acknowledged but not handled as part of this work.

Support executed a full credential regeneration ("All Over Reset") for the affected identities across identity platforms (Okta, Microsoft 365, Atlassian). New access credentials were generated and delivered, and reset notifications/instructions were sent to the user for the affected addresses (including personal Gmail/GMX and IU external addresses). The action was documented in the ticket and no further follow-up was recorded.

Provisioning and access issues were handled by coordinating with the LIBF team and by central administrators. New libfStudy accounts were created by LIBF colleagues when requested and account details (usernames and initial credentials or next-step instructions) were sent to the user's IU.org email address. When instructor/EPOS accounts were required, IU support created EPOS instructor accounts using the libfStudy address and delivered the account details to the user’s IU email. For lost-access/password issues, support provided a self-service password-reset manual for LIBF myCampus and escalated M365/libfStudy password resets to LIBF IT; LIBF IT reset affected M365 passwords and communicated the new credentials via IU email. Tickets were closed after users confirmed access was restored.

New Salesforce user accounts (including UAT environment accounts where requested) were created for the requesters and the referenced user's permission set/profile was replicated so they could access the previously unavailable records. Where reporting history needed to be preserved, the original Salesforce account was left inactive. Identity-provider and email provisioning blockers were handled by coordinating with Okta and the mail team: valid or placeholder email addresses were assigned where required and explicit consent from the original user was obtained before deactivation. When frontline support lacked the rights to perform the cloning, requests were forwarded to the specialist team and requesters were in some cases asked to resubmit via the appropriate Microsoft Form before provisioning proceeded. Requesters were provided the new account details and confirmed they could access the required objects.

Support confirmed the Amazon Business accounts were managed by Strategic Procurement and responded with contact details for that team. The user was directed to contact the procurement mailbox (einkauf@iu.org) to request reactivation rather than having IT perform the reactivation.

Renames were coordinated in person with on-site device-support staff so local macOS account credentials and FileVault access could be reconciled before upstream Okta/email changes. When a remote rename had already resulted in a new blank local account, device support located the original home directory, restored ownership/permissions, migrated user files and application preference data into the active account, and re-established the device-specific credentials so the user could log in. Jamf device state and the Okta-to-local account mapping were validated and adjusted to prevent duplicate-local-account creation or unnecessary reimages. These actions restored the user’s files, application settings, and Mac login without full device reimage.

Support reviewed prior ticket history and authentication logs and noted recent password changes, lockouts, or mailbox deactivation where present. Because users' self-service reset messages were delivered to an institutional IU mailbox they could not access — or because the mailbox had been deactivated after leave — support performed administrative account actions: account unlocks and/or administrative password resets and, when required, invoked the reset-workflow to reactivate the IU mailbox. Support clarified which services used separate credential scopes (for example, myCampus vs Okta), tested authentication to affected services (staff portal/myCampus, Okta, Outlook/ticketing), confirmed successful logins via authentication logs, and notified the user that access was restored.

The administrator updated the user's surname across the affected systems (IU external email and linked services including AB Tasty and the personal email record where applicable). The Okta identity record was corrected where it initially showed no editable name attributes so the canonical surname matched the updated accounts. The user was informed once the name change propagation completed.

Users were removed from Jira teams and associated tags when required. Relevant accounts and administrative privileges were identified and disabled or deactivated in the corresponding systems: Okta (Okta Admin Console), on‑prem Active Directory (AD administration tools), Microsoft Entra ID/Azure AD (Entra/Azure admin center), institutional tenant(s) (IU tenant), TeamViewer (TeamViewer management console), and the user’s email account/mail system (including domains such as iu.org and iu-it.org). External contractor accounts were deactivated (examples: matthias.bauer.ext@iu.org and aleks.zamyarski.ext@iu-it.org). Deactivations were verified and no additional follow-up actions were identified.

Support located the affected user record, reactivated the disabled institutional account, and restored email and device sign‑in access. Investigation consistently found that an incorrect scheduled deactivation/exmatriculation date had been entered in the source system (for example, an offboarding request or a manual "ExMa" date in the student admin portal), and that automation or the deactivation process acted on that date rather than performing an independent error. The issue was resolved by correcting or removing the erroneous scheduled date in the authoritative admin record (for example, the user profile in care-admin.iubh.de), after which normal account lifecycle behavior resumed. In cases where the premature deactivation originated from an offboarding request, users were advised to submit the correct/scheduled deactivation request so the formal closure would occur at the intended time.

Technicians provisioned new corporate Vonage accounts under the name provided or, when an account already existed, confirmed the existing account and restored access by sending a password reset. Duplicate records caused by inconsistent name spellings or template-based requests were identified and handled by confirming the canonical account before proceeding. When a Vonage account existed but no Salesforce user record was present, technicians noted that the Vonage–Salesforce linkage could not be configured until the Salesforce account existed; they coordinated or awaited Salesforce account creation and then configured the integration. Tickets commonly arrived via Salesforce and were closed after the account was provisioned, access was restored, or the Salesforce linkage had been established.

Accounts were reactivated when required and the Workday ID mapping was corrected (back-switched/updated) to consolidate duplicate or mismapped identity records under the employee’s correct Workday identifier. Identity records were merged so the employee operated under a single Workday ID and retained laptop and associated account access. SSO mappings (Okta) and downstream service access (for example Jira) were restored after the consolidation, resolving observed Workday sign-in errors. Microsoft 365 licensing discrepancies were corrected (for example replacing Office A1 with the proper Office A5 entitlement). Access and functionality were verified across affected clients and browsers (Chrome, Edge) after changes.

A new dedicated service account named "s.radiusprobe" was created and the Intermapper RADIUS probe configuration was changed to use the s.radiusprobe account in place of the individual account reinhard.koeppl. The change was confirmed in Intermapper and no subsequent errors were reported.

Support investigated and found the Salesforce user record had been deactivated due to an unverified email. An attempted reactivation reverted when the email remained unverified. The incident was escalated out of the team's remit and the requester was instructed to either complete the email verification link in the user's mailbox or to open a ticket with the responsible identity/support team to request reactivation if verification could not be completed.

Service desk triage identified the correct application/product-owner teams for requests that were misrouted to the central account-provisioning/service-catalog. Metabase access and reactivation requests were handled by the DevOps team. Salesforce account-creation, permission, and event-type-change requests required SalesTech privileges and requesters were directed to the SalesTech Service Portal (Atlassian Service Desk, careerpartner.atlassian.net). Twilio configuration and other application feature/permission changes were routed to the respective product or feature owners. Site Fusion Portal account-unlock requests were referred to the SiteFusion account team (cfe-teaq@iu.org). Tickets were closed after triage once requesters had been directed to the responsible team and given the appropriate submission path when central support lacked the necessary permissions.

Administrators verified the user's Okta account status, application license/assignment, and termination/expiry dates. To isolate authentication, users were asked to sign in directly via Okta and an Okta password reset was initiated. Application-side checks showed that some SaaS products maintained their own account state: IT confirmed SSO and group assignments but found the account disabled inside the application (Qualtrics) with error tag [532f95a7], and Okta administration could not re-enable or modify the app-side account. IT advised escalation to the application owner/vendor (research@iu.org in the reported case) to investigate the application error tag and reactivate the user account. Where no further user response or vendor action occurred, tickets were left unresolved and auto-closed after these remediation steps.

Support staff investigated the Teams access report, discovered the user had two separate accounts, and performed a reset of the affected account. The reset (performed by Schumacher on 2024-07-09 13:51) resolved the authentication conflict and restored the user's access to Teams.

The support team created the new AD account by duplicating the requested template account's attributes and settings. After provisioning the AD object, they removed the unintended Okta group memberships that had been copied to the new account and confirmed the AD/Okta mappings. The provisioning and group cleanup completed successfully and the ticket was closed.